System and method to manage a workflow in delivering healthcare

ABSTRACT

An example system to allocate a resource to a plurality of patients includes a first agent to track a first property associated with a first patient to obtain first tracking data and a second agent to track a second property associated with a second patient to obtain second tracking data. The example system includes a bidding engine to receive the first tracking data from the first agent and the second tracking data the second agent. In the example system, the bidding agent to dynamically generate a first bid associated with the first patient based on the first tracking data and a second bid associated with the second patient based on the second tracking data. The example system includes a broker to assign the resource to one of the first patient or the second patient. In the example system, the broker is to dynamically communicate with the bidding engine to assign the resource based on at least one of the first bid, the second bid, or a property associated with the resource.

RELATED APPLICATIONS

This patent arises from a continuation of U.S. application Ser. No.11/972,888, which was filed on Jan. 11, 2008, and is hereby incorporatedherein by reference in its entirety.

BACKGROUND

The subject herein generally relates to a system and method to manageprogression of a patient through a workflow, and in particular, theworkflow is a healthcare procedure.

Hospitals and other medical facilities (e.g., imaging centers,cardiology treatment centers, emergency rooms, surgical suites, etc.)include various workflows to deliver diagnosis or treatment to admittedpatients. These workflows are comprised of events that employ variousresources, such as imaging rooms, physicians, nurses, radiologists,cardiologists, clinicians, technicians, or transcriptionists. Theseworkflows are often unstructured and non-linear in nature due to complexconditions that dynamically evolve at any point in time of the workflow.

Known systems and methods to manage patients through these workflowsdelivered at healthcare facilities are generally static andnon-adaptive. These known systems generally rely on past data and lineardesign assumptions to manage workflows (e.g., diagnostic imaging,cardiac treatment, etc.). As a result, these known systems and methodsare generally inflexible or unresponsive to non-linear changes or eventsthat increase the likelihood of chaos due to complex conditions thatevolve in real time beyond the original linear design. Examples ofparameters to measure a quality of service or efficiency of workflowsinclude, but are not limited to, patient wait times, procedureturn-around times, resource utilization, etc. For example, increasingprocedure turn-around times can increase underutilization of resources(e.g., an imaging room sitting idle).

BRIEF SUMMARY

Thus, there exist a need for a system and method for real-timemedical/clinical workflow management and optimization. The system needsto be multi-variant to address variation demand and urgency, diverseprocedure goals, custom workflows without standard work times, unusedcapacity, excess waiting by patients, and delay of critical decisionmaking due to lack of critical information. The above-mentioned problemsand needs are addressed by the subject matter described herein in thefollowing description.

According to one embodiment, a method to manage progress of a pluralityof patients through a workflow of events in delivering healthcare isprovided. The method comprises the steps of tracking at least oneproperty of more than one of the plurality of patients to progressthrough workflow of events; calculating a bid of the more than one ofthe plurality of patients relative to one another, the bid directed to aslot in the schedule of at least one resource utilized in the workflowof events in delivering healthcare, the bid dependent on a tracked dataof the at least one property of the more than one of the plurality ofpatients; and assigning one of the more than one of the plurality ofpatients to the slot in the schedule of the at least one resourcedependent on a comparison of the bid of each of the more than one of theplurality of patients relative to one another.

According to another embodiment, a system to manage progression of aplurality of patients through a workflow of events that employs at leastone resource in delivering healthcare is provided. The system comprisesat least one sensor operable to track at least one property of more thanone of the plurality of patients; and at least one processor incommunication with the sensor. The at least one processor is operable toexecute a plurality computer readable program instructions generallyrepresentative of the steps of calculating a bid of the more than one ofthe plurality of patients relative to one another directed to a slot ina schedule of utilization of the at least one resource dependent ontracked data of the at least one property of the more than one of theplurality of patients, and assigning one of the more than one of theplurality of patients to the slot in the schedule of the at least oneresource dependent on a comparison of the bid of each of the more thanone of the plurality of patients relative to one another.

According to yet another embodiment, a dashboard to manage progressionof a plurality of patients through a workflow of events that employs atleast one resource in delivering healthcare is provided. The dashboardcomprises a display illustrative of an identifier of the at least oneresource, and further illustrative of an identifier of the more than oneof the plurality of patients in an arrangement according to order of arespective value of the bid of each of the more than of the plurality ofpatients directed to the slot in the schedule of the at least oneresource.

Various other features, objects, and advantages of the disclosure willbe made apparent to those skilled in the art from the accompanyingdrawings and detailed description thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic overview of an embodiment of system to manage aworkflow.

FIG. 2 is a flowchart illustrating an embodiment of a method to managethe workflow with the system of FIG. 1.

FIG. 3 is a schematic diagram illustrating another embodiment of asystem to manage a workflow in a clinical environment.

FIG. 4 is a block diagram illustrating another embodiment of a system tomanage a workflow to schedule a patient to undergo medical imaging.

FIG. 5 is a pictorial illustration of another embodiment of a system tomanage a workflow in a clinical environment.

FIG. 6 is a flowchart illustrating another embodiment of a method ofmanaging a workflow to schedule patients for a clinical procedure.

FIG. 7 is illustrative of an embodiment of a dashboard operable toreport an output of the system at any point in time of a patientprogressing through the workflow.

FIG. 8 is illustrative of another embodiment of a dashboard operable toreport an output of the system at any point in time of a patientprogressing through the workflow.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings that form a part hereof, and in which is shown byway of illustration specific embodiments that may be practiced. Theseembodiments are described in sufficient detail to enable those skilledin the art to practice the embodiments, and it is to be understood thatother embodiments may be utilized and that logical, mechanical,electrical and other changes may be made without departing from thescope of the embodiments. The following detailed description is,therefore, not to be taken as limiting the scope of the disclosure.

FIG. 1 illustrates a schematic diagram of an embodiment of a system 100to manage a patient 105 through a workflow having an increasedprobability or likelihood toward chaos due to complex, non-linearconditions. The complex conditions can evolve in general real timebeyond an original or predetermined design before the start of theworkflow.

An embodiment of workflow as herein used can generally be defined as anembodiment of a sequence of tasks or states or or steps or events (e.g.,physician examination, laboratory tests, acquire electrocardiogram (ECG)data, etc.) that may or may not employ use or operation or involvementof a series of resources 110, 112, 114 to deliver a defined outcome(e.g., treatment of the patient 105 for chest pain, broken arm, trauma,illness, etc.). The number of resources 110, 112, 114 can vary. Anembodiment of the resources 110, 112, 114 can be operable to interactwith each other in general real- time, as well as be operable toestablish a logical relationship among one another. The resources 110,112, 114 may be included at the beginning of the workflow or in generalreal time during or between the events or steps of the workflow. Oneembodiment of the resources 110, 112, 114 include a physician 110, animaging or scanning system 112, and a laboratory device 114. Yet, theresources 110, 112, and 114 can include test laboratories, etc. or anyimaginable element involved in treatment or study of the patient 105.

An embodiment of each of the series of resources 110, 112, 114 and thepatient 105 can be assigned with at least one property 116, 118, 120,121, respectively. The type and number of properties 116, 118, 120, 121can vary. The properties 116, 118, 120, 121 may be static so as toremain the same throughout the workflow. The properties 116, 118, 120,121 can also be dynamic with an ability to change with time. Forexample, an “elapsed time” can be one of the properties 116, 118, 120,121. Generally, the properties 116, 118, 120, 121 are predeterminedprior to or at the beginning of the workflow. However, the properties116, 118, 120, 121 can be identified or added while executing theworkflow in general real-time. For example, one or more properties 116,118, 120, 121 can be added to track a chaos or unpredictability of theavailability of the resources 110, 112, 114 or events in the workflow.Another example of tracked properties 116, 118, 120, 121 include thecapacity of technicians, capacity of physicians, capacity of facility,or any element involved in the workflow. Another example of the workflowin the clinical environment includes an investigational study whereresources 110, 112, 114 include an ultrasound system 110 and anultrasound operator 112 to perform a cardiac exam, where the ultrasoundoperator's skill and knowledge of anatomy is employed to gather themedical information from or for the study. In each case, wait times andlists of the series of patients 105 can vary in a non-linear manner.

An agent 122, 124, 126, 127 generally includes computer-readable programinstructions in or not in combination with one or sensor devices (e.g.,clocks, timers, blood pressure monitors, electrocardiogram (ECG)monitors, temperature monitors, etc.) created to correlate with eachresource 110, 112, 114 or the patient 105, respectively. Each agent 122,124, 126, 127 is generally operable to track or identify changes in theproperties 116, 118, 120, 121 associated with each of the resources 110,112, 114 and the patient 105, respectively. The agents 122, 124, 126,127 can be created upon introduction or creation of the respectiveresource 110, 112, 114 or patient 105 into the workflow. The agents 122,124, 126, 127 are generally operable to communicate or collaborate ingeneral real-time with one another, as well as with the respectiveresources 110, 112, 114 or patient 105. FIG. 1 shows the agents 122,124, 126, 127 located at the respective resource 110, 112, 114 or thepatient 105, respectively. Yet, it should be understood that one or moreof the agents 122, 124, 126, 127 can otherwise be located at a centralcontroller or server 128.

One embodiment of the agents 122, 124, 126, 127 are configured to sense,detect, or track a presence and an awareness. Presence generally refersto an ability of the agent 122, 124, 126, 127 to express or communicatea current state of activity (e.g., available, partially in-use, fully inuse, etc.) of itself to other agents 122, 124, 126, 127 in the system100. For example, presence can include identifying or detecting whetheranother particular agent(s) 122, 124, 126, 127 is available, and ifavailable, to communicate or collaborate its availability to theparticular agent(s) 122, 124, 126, 127. Awareness generally refers to anability of the agent 122, 124, 126, 127 to sense a presence of otheragents 122, 124, 126, 127 or resources 110, 112, 114 or patients 105 inthe system 100. For example, awareness can include an ability to trackthe activities of other resources 110, 112, 114 or patients 105 in theworkflow. The combination of presence and awareness enables each agent122, 124, 126, 127 to initiate a communication with one another toidentify or calculate a length of time to get a response from oneanother. Awareness also allows the agent 122, 124, 126, 127 initiating acommunication to make decisions about mode of communication (e.g.,route, wireless versus wired connection, etc.) to establish contact. Anability to express or communicate the presence and leverage theawareness allows the agents 122, 124, 126, 127 to initiatecommunications with one another and to respond to communications fromother agents 122, 124, 126, 127.

Examples of agents 122, 124, 126, 127 can receive/communicate patientdata, receive/communicate requests for a work order and a report status,receive/communicate patient notifications to report for an event or stepin the workflow (e.g., testing, imaging), and receive/communicateproblems. Examples of agents 122, 124, 126, 127 are also operable tocontact respective physicians waiting for critical patient informationusing an identified best mode of communication (e.g., beeper, hometelephone, email, cellular phone, text message, etc.). Additionally,physicians 110 or patients 105 can communicate via computer messagingsystems or other known type of input (e.g., keyboard, touch-screen,voice recognition, etc.) with the agents 122, 124, 126, 127 in theworkflow community to gain access to information and collaborate withagents 122, 124, 126, 127 at any given point in time of the workflow.

An embodiment of the agents 122, 124, 126, 127 can be configured tocollaborate in calculating or assigning a priority status 129 of eachpatient 105 to one or more available the resource 110, 112, 114 employedin the workflow relative to other patients 105. Vice versa or inaddition, the agents 122, 124, 126, 127 can be configured- tocollaborate in calculating priority statuses 130, 132, 134 of eachresource 110, 112, 114 to each patient 105. Of course, the number ofpriority statuses 129, 130, 132, 134 can vary with the number ofresources 110, 112, 114 and patients 105. The priority statuses 129,130, 132, 134 are created or assigned via the collaboration orcommunication of the agent 122, 124, 126, 127. The agents 122, 124, 126,127 collaborate with one another to calculate or create the prioritystatus the patient 105 for each resource 110, 112, 114 dependent onmiscellaneous factors, including but not limited to, the trackedproperties 116, 118, 120, 121 of all the resources 110, 112, 114 and thepatients 105 in the system 100 tracked in general real-time or any givenpoint in time of the workflow. A technical effect of the priority status129, 130, 132, 134 is to generally define the criticality of eachpatient 105 relative to one another with respect to each of theresources 110, 112, 114 at any given point of time, or vice versa, thepriority of each resource 110, 112, 114 to each patient 105 at any pointin time. The agents 122, 124, 126, 127 can dynamically re-assign orre-set the priority statuses 129, 130, 132, 134 at generally any pointin time of the workflow. If a new resource is added in the workflow, anew agent is assigned or created for that new resource, where the newagent tracks the one or more properties of the new resource with timeand interacts or collaborates with other agents 122, 124, 126, 127 tocalculate the priority status of each relative to one another.

For example, the agents 122, 124, 126 can track the number of uses oroperations of the resources 110, 112, 114 of the system 100. Afterdetecting a predetermined number of uses, the agents 122, 124, 126 canautomatically communicate a signal to other agents 122, 124, 126, 127that one or more of the resources 110, 112, 114 is not available (e.g.,maintenance, end of life, etc.), or create a purchase order or leaserequest for its replacement resource 122, 124, 126. The series of agents122, 124, 126, 127 can include, or the system 100 can further include,an additional agent having a general ability to supervise or track allof the resources 110, 112, 114 and patients 105 in the workflow, andidentify or detect for errors (e.g., critical patient needs or wait timenot being met in a timely manner).

The embodiment of the workflow management system 100 further includes anassessment or bidding engine 140. Although the bidding engine 140 isillustrated at the central server or computer 128, it should beunderstood that the bidding engine 140 can be located at any of theresources 110, 112, 114 of the system 100. An embodiment of the biddingengine 140 is generally operable to create or calculate or generate anassessment index or bid. One embodiment of the bid is a value indicativeof a priority status of each patient 105 relative to one anotherdirected to a slot in the schedule of operation or utilization of one ormore of the resources 110, 112, 114. An embodiment of a slot is a blockor allotted time frame or period initially predetermined by hospitaladministration and modified in view of tracked properties (e.g.,maintenance, current utilization, fail condition, undergoing cleaning,etc.) of the resources 110, 112, 114. Vice versa, the assessment indexor bid can include a value representative of a value of priority statusof allocation of each resource 110, 112, 114 to each patient 105relative to the other resources 110, 112, 114. Another embodiment of theassessment index or bid is generally representative of a value ofpatient risk or criticality of if not to receive treatment by or haveaccess to (e.g., a slot in the schedule) one or more of the resources110, 112, 114 relative to other patients 105. The more critical a healthcondition of the patient 105 or the greater a wait time of the patient105 generally results in a greater value of patient risk or criticalityrelative to others. Yet another embodiment of the assessment index orbid generally represents a value or amount indicative of an availabilityeach resources 110, 112, 114 (e.g., readiness to utilize (clean, not duefor maintenance, not failed), location relative to patient, etc.)relative to the others as to be employed on each patient 105 in one ormore steps in the workflow.

The bidding engine 140 generally calculates or creates each biddependent on a series of factors, including the current priority status129, 130, 132, 134 assigned or created for each patient 105 or eachresource 110, 112, 114, and a wait time of each patient 105 for eachresource 110, 112, 114. In an example, the bidding engine 140 calculatesthe bids in general real-time (e.g., at any point in time) dependent onthe priority status of each patient 105, which is calculated atregistration and updated or created with detected changes in theproperties 116, 118, 120 of each of the resources 110, 112, 114 astracked and communicated by the agents 122, 124, 126, respectively.

The bidding engine 140 can communicate with the agents 122, 124, 126 toreceive the priority statuses 130, 132, 134 to each resource 110, 112,114. Alternatively, the bidding engine 140 can collaborate incombination with the agents 122, 124, 126 to create or calculate thepriority status of each resource 110, 112, 114 to each patient 105. Oncethe bidding engine 140 receives or creates the priority statuses 130,132, 134, the bidding engine 140 calculates a bid dependent on a set ofbidding policies for each available resource 110, 112, 114 employed inthe workflow. Dependent on the value of each of the bids and the numberof patients 105, the bidding engine 140 also calculates or adjusts theslots in the schedule to use or access each resource 110, 112, 114. Thebidding engine 140 can dynamically update or change or recalculate(e.g., continuously or periodically) the schedule of the resources 110,112, 114 with changes in their priority statuses, which can becorrelated to or dependent on changes in the properties 116, 118, 120(e.g., downtime for failure or routine maintenance, utilization, etc.)of each of the resource 110, 112, 114 respectively, at any point in timein the workflow.

The system 100 can also include a broker 150 in communication orcombination with the bidding engine 140. An embodiment of the broker 150generally evaluates which of the series of patients 105 holds thehighest bid to each of the resources 110, 112, 114. A technical effectof the broker 150 is generally operable to optimize (e.g., reduceoverall wait time of patients, allocate resources for greatestutilization, etc.) the workflow dependent on a series of factors,including the bids calculated or created for each resource 110, 112,114, the availability of resources 110, 112, 114, and the availableviable options. The broker 150 can be located with any of the resources110, 112, 114 or at the central server 128. One embodiment of the broker150 is operable or configured to change one or more properties 116, 118,120, 121 of the resources 110, 112, 114 or patient 105, respectively, orchange one or more of the bids generated by the bidding engine 140,dependent on tracked changes to the properties 116, 118, 120, 121 of thepatient 105 or to one or more of the resources 110, 112, 114. Forexample, some of the properties 116, 118, 120, 121 may becomeinsignificant with time. The broker 150 can configure or communicatewith the agents 122, 124, 126, 127 to end or discard tracking ofinsignificant properties at any point in time.

Another embodiment of the broker 150 is generally operable or configuredto alter, modify, suggest, or cancel steps or events in the workflowdependent on the priority status 130, 132, 134 of each patient 105 tothe one or more resources 110, 112, 114. Assume, for sake of example,that the agent 127 of the patient 105 in a clinical workflow tracks theproperty 121 generally representative or indicative of a senior citizenof physical condition such that undergoing a treadmill test isundesired. In response to identifying or detecting this property 121,the broker 150 can modify the workflow to skip the step of the treadmilltest in the workflow. The broker 150 can be further configured to changethe schedule or priority status 130, 132, 134 to the otherwise scheduledresources 110, 112, 114 according to the detected change in theproperties 116, 118, 120, 121.

Assume, for another sake of another example, that resource 114 employedin the workflow (e.g., clinical procedure) is a scanner, and that thescanner agent 124 has detected or identified that the tracked scannerproperty 118 is indicative that the scanner 112 has failed or isoverloaded or otherwise generally unavailable. The broker 150 isgenerally operable to re-calculate bids of each patient 105 in view ofalternative options to provide treatment to the patient 105 at a minimalcost. For example, the broker 150 can locate another resource (e.g.,search inventory) having the same or similar function as the scanner 114that is available for use (e.g., identify another imaging room withanother available scanner). The property 118 being tracked by thescanner agent 124 can include a capacity of the scanner 112, and anotherproperty 121 tracked by the agent 127 can include a tracked wait time touse the scanner 112. The updates or changes to the tracked values orstatuses of these properties 116, 118, 120, 121 directed to capacity orwaiting time can be communicated to the bidding engine 140 or broker150. In response, the broker 150 can re-create or adjust the schedule ofeach respective patient 105 or resource 110, 112, 114, the broker 150can change one or more bidding policies that constrain or defineboundary conditions of the bidding engine 140, or the broker 150 canchange the workflow to skip the event or step involving the scanner 112,or the broker 150 can create a purchase order or lease request for anadditional resource similar in function to the scanner 112.

An embodiment of the broker 150 can be further configured to modify anoperational profile of one or more of the resources 110, 112, 114 or thepatient 105. An embodiment the broker 150 can also be configured tochange the measured values or the tracking of the properties 116, 118,120, 121 in relation to time or the workflow. For example, if the waittime of any one patient 105 exceeds more than the maximum set time, thebroker 150 can change the one or more properties 116, 118, 120, 121 of,or the bid calculated for, each of the patients 105 so as to selectivelycause an increase or decrease in the priority status of any one patient105 exceeding in wait time relative to other patients 105. To accomplishthis, upon detecting the wait time of one patient 105 to exceed thethreshold of wait time, the broker 150 calculates the bid of the onepatient 105 tracked that exceeds in wait time with a bid of valuegreater than, or calculate the bid value to be an order or more ofmagnitude greater than, the bid value of any other patient 105.

For example, assume the resource 112 is generally representative of abuyer, and resource 114 is generally representative of a supplier. Thesuppliers 114 provide various services, and the buyers 112 avail to theservice of the suppliers 114. The suppliers 114 and the buyers 112 haverespective properties 118, 120 and the agents 124, 126 track or measurethe properties 118, 120 or changes thereto at any instant of time. Theagents 124, 126 collaborate or communicate with one another to calculateor create a priority status of each buyer 112 and supplier 114 relativeto one another. The bidding engine 140 receives the priority statusesfor the buyers and suppliers 112 and 114, and dependent thereon createsa schedule for the services provided by the suppliers 114 to avail tothe buyers 112. Accordingly, rather than being driven solely by the nextsequential task, the system 100 is also operable to schedule and managethe workflow according to other factors, including a capacity of theresources 112, 114 employed in the workflow relative to one another.

The system 100 is generally operable via the agents 122, 124, 126, 127to track the dynamics of individual or population of patients 105 overtime and their respective needs and demands on other resources 112, 114.Objective functions of the system 100 include increasing an “efficiency”from a standpoint of the healthcare or service provider, and increase an“equity” (e.g., wait time) from a standpoint of the patient 110 in theworkflow managed by the system 100. The bidding engine 140 and broker150 are operable to communicate or collaborate with one another and theagents 122, 124, 126, 127 to create or adjust the bidding policies orthe workflow so as to select the optimal bidding policy for theworkflow. The system 100 is generally operable in continuous time andcontinuous space.

An embodiment of the controller 128 is connected in communication witheach of the agents 122, 124, 126, 127, bidding engine 140 and broker150. An embodiment of the controller 128 includes a memory or database155 generally operable to receive updated values or measurements oftracked properties 116, 118, 120, 121 on a continuous or periodic basisof the resources 110, 112, 114 or patient 105, respectively, receive newproprieties with respect to new resources or additional patients 105,bids of each patient 105 for each of the resources 110, 112, 114 at apoint or instant of time of the workflow, a calculated schedule, etc.

The controller 128 can also include a processor 160 generally configuredto execute program instructions store in the memory 155. Although thememory 155 and processor 160 are shown at the computer 128, it should beunderstood that an embodiment of the agents 116, 118, 120, 121, thebidding engine 140, or the broker 150 described above can each includeprocessors in communication with memory or storage medium ofcomputer-readable program instructions located at one of the resources110, 112, 114.

An embodiment of the system 100 may further include a series of a meansof sensing or sensors 170, 172, 174, 176 operable to track a location ofeach patient 105 or resource 110, 112, 114, respectively, with respectto a reference or to one another. An embodiment of each sensor 170, 172,174, 176 is operable to communicate a location of each patient 105relative to a predetermined reference. The sensors 170, 172, 174, 176can be operable to track in coordinates, or by room or floor number,etc. The sensors 170, 172, 174, 176 can be in wireless communicationwith a receiver 180 connected in communication with the controller 128.An embodiment of the sensors 170, 172, 174, 176 can include acombination of transmitters in electromagnetic communication withreceivers, transmitters in communication with receivers directed toradio frequency identification (RFID), optical sensors, globalpositioning system (GPS) in communication with satellite(s), etc. orother position measuring or locating technology known in the art orcombination thereof

FIG. 2 includes a schematic flow diagram illustrating an embodiment of amethod 200 of operation of the system 100 to dynamically manage (e.g.,scheduling) the patient(s) 105 through events of the workflow thatemploys the series of resources 110, 112, 114. It should also beunderstood that the sequence of the acts or steps of the method 200 asdiscussed in the foregoing description can vary. Also, it should beunderstood that the method 200 may not require each act or step in theforegoing description, or may include additional acts or steps notdisclosed herein. It should also be understood that one or more of thesteps of the method 200 can be represented as computer-readable programinstructions for execution by one or more processors of the agents 122,124, 126, 127, the bidding engine 140, the broker 150, the centralserver 128, or at any of the resources 110, 112, 114.

Step 210 includes assigning or identifying the properties 116, 118, 120,121 to each of the patients 105 or resources 110, 112, 114 identified asemployed in the workflow. An embodiment of step 210 includes identifyingvarious steps or events involved in the workflow, and identifying theresources 110, 112, 114 and patients 105 involved in the steps or eventsof the workflow. The patients 105 or resources 110, 112, 114 andrespective properties 116, 118, 120, 121 can also be identified or addedat any point or instant in time of the workflow.

Step 220 includes identifying or creating the agent 122, 124, 126, 127corresponding to each resource 110, 112, 114 and the patient 105. Anembodiment of the agents 122, 124, 126, 127 are configured to track atleast one property 116, 118, 120, 121 (e.g., dynamic property) of thepatients 105 or resources 110, 112, 114 at any point in time of theworkflow. The agents 122, 124, 126, 127 are further configured to trackand communicate measurements of the tracked properties 116, 118, 120,121 relative to one another and any changes thereto in generallyreal-time (e.g., continuously or periodically updated through workflow).The agents 122, 124, 126, 127 are further configured to collaborate orcommunicate the tracked status or values of the properties 116, 118,120, 121 with one another via general direct or indirect interaction orcommunication among the agents 122, 124, 126, 127 or the resources 110,112, 114 involved in the workflow.

Step 230 includes calculating or creating the priority status of eachpatient 105 to each resource 110, 112, 114. Vice versa, step 230 caninclude calculating or creating the priority status of each resource110, 112, 114 to each patient 105. One embodiment of step 230 includeseach agent 122, 124, 126, 127 tracking different properties 116, 118,120, 121 of the resources 110, 112, 114 or patient 105 to which it isassociated. The agents 122, 124, 126, 127 can also be operable tocommunicate the tracked values or states of the properties 116, 118,120, 121 of the respective resources 110, 112, 114 or patient 105relative to one another. By collaborating or communicating with oneanother or the resources 110, 112, 114 or patient 105, the agents 122,124, 126, 127 calculate or assign or identify a priority status of thepatient 105 to each resource 110, 112, 114 relative to other patients105.

Step 240 includes the bidding engine 140 calculating the bid of eachpatient 105 to each of the resources 110, 112, 114, or vice versa,calculating a bid of each resource 110, 112, 114 to each patient 105, ina general bidding process, dependent on the priority statuses calculatedin step 230. The bidding engine 140 generally co-ordinates this biddingprocess for each of the one or more events of the workflow. Oneembodiment of the bidding engine 140 calculates the bid of each patient105 to each resource 110, 112, 114 depending on a series of factors orbidding policies, including but not limited to, the received prioritystatus of the patient 105 as calculated by each agent 127, capacity ofthe resources 110, 112, 114 or workflow, a wait time of any individualpatient 105, and an availability or status of utilization (e.g., clean,due for maintenance, failed condition, inventory, in use, etc.) of theresources 110, 112, 114 that can limit or place a boundary condition onthe bidding process, and a sequence of the workflow. For example, thebidding engine 140 can calculate or simulate a plurality of the possiblecombinations of allocations of resources 110, 112, 114 to be employed inthe workflow per the patients 105 in the workflow, and calculate one ofthe plurality of possible or candidate combinations that best optimizes(e.g., minimum patient wait time, maximum throughput capacity, lowestcost, etc.) the workflow.

Step 250 includes the broker 150 calculating or comparing bids generatedby the bidding engine 140 so as to allocate or assign each of thepatients 105 to each of the slots in the schedule of the resources 110,112, 114, or vice versa, the allocation of the resources 110, 112, 114to the schedule of each of the patients 105. The broker 150 may alsoalter, modify, suggest, or cancel one or more events in the workflow viatracking of one or more properties 116, 118, 120, 121 of the resources110, 112, 114 or patient 105 in relative to time and the workflow, orchange the bids of one more patients 105 or resources 110, 112, 114dependent on updated changes to tracked data of one or more properties116, 118, 120, 121.

FIG. 3 illustrates an embodiment of a system 300 to manage a workflow ina clinical environment, similar to the system 100 described above. Anexample of workflows in a clinical environment includes a nuclearmedicine cardiac study comprised of a succession of steps, and potentialwait times between each phase of the study.

The workflow requested by a patient 310 can include the followingresources: a physician 312, clinician 314, technician 316, facility 318,remote server 320, a medical equipment or device 322, and a clinicalequipment or device 324. Of course, the types and number of resources312, 314, 316, 318, 320, 322, and 324 can vary. Properties identified orassigned to be tracked for each patient 310 at the time of admission orregistration can include a patient priority classification as a chronicversus critical condition, an ability to exercise, a predicted stresstest time for cardiac evaluation, weight, etc. in accordance toinformation provided by the patient 310 in a simple self-assessmentquestionnaire, similar to the properties 116, 118, 120, 121 describedabove. The properties can also include a liver clearance time or otherproxies calculated in the case of a Nuclear Medicine study workflow.

Agents 325, 327, 329, 331, 333, 335, 337, 339, 341 can be created totrack the one or more dynamic properties of each respective resources310, 312, 314, 316, 318, 320, 322, 322, 324. An embodiment of thepatient agent 325 tracks different properties of the patients 310 towhich it is associated, and calculates a representative current state ofactivity of the patient 310. The patient agent 325 is in communicationwith other agents 327, 329, 331, 333, 335, 337, 339,341 of the system300. The agents 325, 327, 329, 331, 333, 335, 337, 339, 341 interact orcommunicate with one another to calculate a priority status of patient310 to each of the resources 312,314, 316, 318, 320, 322, 322, 324relative to other patients 310 admitted to the workflow. The patientagents 325, 327, 329, 331, 333, 335, 337, 339, 341 may themselvescalculate each priority status or in combination with the help of theserver 335. The agent 325 can track the dynamic properties on an as-needbasis, period basis, or continuously through the workflow. For example,if the property of the patient 310 is classified in critical condition,the agent 325 can track the patient's blood pressure every five minutes,and this time interval can adjust with changes in the blood pressure.

The system 300 also includes a bidding engine or scheduler 344 and abroker 346, similar to the bidding engine 140, and broker 150 of thesystem 100 described above. If the property of the patient 310 isclassified or identified or calculated as an emergency or critical, theagent 325 or the bidding engine 344 may automatically calculate orassign a highest priority status to the patient 310 to push through theworkflow at a reduced time relative to other patients. In anotherexample, if a property or bidding policy is representative of a maximumwait time of the patient 310 is set for three hours prior to or duringthe workflow, then even if the patient is otherwise of a low prioritystatus based on the other properties, the bidding engine 344 mayincrease the bid so as to cause broker 346 to and schedule the patient310 ahead of others waiting for the medical or clinical device 322 or300, respectively.

An embodiment of the medical device 322 can include a processor 348generally operable to execute the functions (represented as computerreadable program instructions) of the medical device 322 or agent 339.An embodiment of the clinical device 324 can also include a processor350 that executes functions (represented as computer readable programinstructions) of the clinical device 324 or agent 341. An embodiment ofthe agent 339 created in correspondence to the medical device 322 can beoperable to track at least one property, including a failure status, ora patient handling capacity of the medical device 322. In such asituation, the agents 325, 327, 329, 331, 333, 335, 337, 339, 341 cancollaborate or communicate with one another to calculate or create apriority status of the patient 310 to each of the medical device 322 orthe clinical device 324 relative to one another.

The patient agent 325 communicates the priority status of each patient310 to the bidding engine 344. The bidding engine 344 also receives thepriority status from the agents 327, 329, 331, 333, 335, 337, 339, 341correlated to the respective physician 312, clinician 314, technician316, facility 320, medical device 322 or clinical device 324. Dependenton the received priority statuses, the bidding engine 344 calculates thebid, as described above, of each patient 310 for an opportunity to oneof the slots in the schedule of the one or more of the physician 312,clinician 314, technician 316, facility 318, remote server 320, amedical equipment or device 322, and clinical equipment or device 324,or vice versa, similar to the bidding engine 140 of the system 100described above. The bidding engine 344 can be located at either themedical device 322 or the clinical device 324 or at a server associatedtherewith.

In accordance with one or more bidding policies created for the workflowand the series of received priority statuses, the bidding engine 344 canidentify the multiple schedule combinations that employ the one or morepatients 310 in the slots of the schedule of the physician 312,clinician 314, technician 316, facility 320, medical device 322 orclinical device 324. The bid of each patient 310 to slots in theschedule of each of the physician 312, clinician 314, technician 316,facility 320, medical device 322 or clinical device 324 can be alteredat any time with a change in a tracked property, and the bidding engine344 can re-calculate the slots in the schedules accordingly so as toincrease but not overload a patient handling capacity of the physician312, clinician 314, technician 316, facility 320, medical device 322 orclinical device 324, or to reduce the wait time of each patient 310, andto increase the overall capacity of the workflow.

Another example of a property that can be tracked by one of the patientagents 325 includes a need (e.g., patient in critical or emergencycondition) to expedite a clinical study (e.g., catheter lab). Havingtracked a change in the expedited need property of the patient 310, theagent 325 can collaborate with the other agents 327, 329, 331, 333, 335,337, 339, 341 to re-calculate the priority status of each, andautomatically communicate the changes in the priority statuses to thebidding engine 140. The tracked property or measured value or status(e.g., expedited need or critical condition of the patient 310) can bemodified throughout the progression through the sequence of steps inworkflow (e.g., clinical study). Tracked data acquired duringprogression through the sequence of steps can be encoded in a patientrecord and stored in at the database 355 (e.g., picture archival system,electronic medical record (EMR), etc.). Dependent on changes in thetracked data, the agents 327,329, 331,333, 335, 337, 339, 341 track(e.g., continuously, periodically, etc.) communicate collaborativechanges in the priority status of each to the bidding engine 344,thereby contributing to the bidding engine 344 calculating bids that canpush or increase the priority status of one patient 310 relative others.In this way, the system 100 can track and schedule according to slicesof events or time in the workflow of the study relative to changes inthe criticality of the health or emergency of each of the patients 310and changes to the availability of patients 310 or the physician 312,clinician 314, technician 316, facility 320, medical device 322 orclinical device 324.

The broker 346 is generally operable to review or re-calculate or adjustor change the assignment of one or more of the patients 310 to slots inthe schedule of each of the medical devices 322 or clinical devices 324with every completion of an event or step (e.g., a test) in theworkflow. The broker 346 can also identify or detect the patient 310with the highest priority status in accordance to the bid generated bythe bidding engine 344 relative to properties tracked by the system 300,including a capacity of the workflow, the wait-time, the time to processthrough the workflow, etc. For example, each of the bids of each of thepatients 310 to each slot in the scheduled period of operation of theresources 310, 322, 324, based on properties, current condition,applicability for the sequence of steps or events in the study or testand their derived current priority. Each patient 310 may be given anoutput device (e.g., pager, email device, etc.) or number to signaltheir assignment to the slot in the study or test. Accordingly, thebidding engine 344 in combination with the broker 346 negotiates andre-negotiates how the each patient 310 is assigned to the slots ofscheduled operation of the medical device 322 or clinical device 324 ofthe system 300, or vice versa, with changes in the tracked properties ofeach patient 310 or resources 310, 322, 324.

Further, additional bidding policies or rules or properties (e.g., withrespect to the bids or schedule of the medical device 322 or clinicaldevice 324) to track the relative wait times on each of the remainingpatients 310 so as to create or cause boundary conditions such that nopatient 310 times-out (i.e., exceeds the maximum wait time) relative toeligibility to the respective resource 310, 322, 324, such as in thecase of injection of biophysical markers (i.e. nuclear medicine), orpriority relative to a criticality of diagnostic need.

The system 300 is also operable to analyze and create a report 360(e.g., graphic display on a monitor, printout, etc.) illustrative of thetracked properties described above to track a performance/efficiency ofor trends in the workflow relative to changes in admissions or patientpopulations, different patient groupings, changes in availability ofresources 310, 322, 324, changes in procedure, etc. Accordingly, thesystem 300 can calculate and report metrics or trends, based on acquireddata of the various properties described above, to predict or increase athroughput of the workflow relative to a patient population andgroupings over a period of time. Other metrics that can be tracked andreported by the system 300 include costs versus throughput of admission(e.g., number per day, time per patient) in the workflow.

In view of the report 360 of tracked metrics and trends in theproperties described above, the bidding policies can be altered, added,or deleted to re-define or change the rules directed to reducing thewait time of the patient 310 or to increase the availability ofresources 310, 322, 324 in the workflow. The broker 346 is generallyoperable to change bidding policies when the system 300 is stressedbeyond a normal or predetermined operating capacity that may beassociated with a demographic shift in service area for a nuclearmedicine machine that may otherwise cause lower than expectedefficiency. The broker 346 is operable to track deviations in thetracked properties or priority statuses or schedule of the physician312, clinician 314, technician 316, facility 320, medical device 322 orclinical device 324. The broker 346 is also operable to simulate ormodel the properties, priority statuses, schedule so as to calculateresulting progress of patients 310 through the workflow according to anew or change in bidding policy of the system 300. The broker 346 cancalculate the above-described simulations periodically in time, or witharrival of each patient or admission in the workflow, and track changesin the simulated values relative to realized values.

An embodiment of the system 300 can be operable to manage a workflowthat comprises several workflows among several medical facilities. Forexample, the workflow can include a workflow through a trauma unit, aworkflow through an emergency unit or room, and a workflow through anurgent care unit where there is overlap in services or steps/events ofthe workflow. According to the tracked properties of each of thepatients 310, the physician 312, clinician 314, technician 316, facility320, medical device 322 or clinical device 324, the system 100 isoperable to evaluate various combinations of scheduling the one morepatients to one or more of the patient 310, the physician 312, clinician314, technician 316, facility 320, medical device 322 or clinical device324 employed among the various workflows (e.g., trauma, emergency,urgent care) described above that is most efficient (e.g., lowestpatient wait time, largest throughput of admissions, etc.) in view ofpredicted trends calculated from historical data of the trackedproperties of the physician 312, clinician 314, technician 316, facility320, medical device 322 or clinical device 324 and of the patients 310(e.g., peak demand at particular times, etc.).

FIG. 4 illustrates another embodiment of a system 400 to managescheduling of a series of patients 410 through a workflow. An agent 415is created for each patient 410 so as to track at least several of theproperties identified for the patients 410, similar to the agents 127and 325 described above. The agent 415 can be created at the beginningof the workflow in accordance to the clinical procedure (e.g., list ofproperties are predetermined, identified, and stored for each of aseries clinical procedures for later recall per an input at theadmission of the patient 410). Various types of properties (e.g.,ability to exercise) can be measured, added or deleted from tracking bythe patient agent 415 in accordance to data acquired from self-screeningor in conducting a preliminary screening of the patient 410. Examples ofstatic properties include the patient's age, a maximum wait time, ausage of a pacemaker, etc. Examples of dynamic properties that maychange with time include an injury to the patient, blood pressure,criticality of the patient 310, change in consciousness, time limitsassociated with use of nuclear medicines or markers, etc. One or morepatient properties may be created in general real time duringprogression through the steps or events of the workflow. For example, ifthe patient 410 starts to bleed, the agent 415 may create a property totrack a degree of bleeding of the patient 410, which otherwise may nothave been defined as a property at the time of admission or prior tostart of the workflow (e.g., diagnostic imaging, clinical study,catheterization, etc.).

Assume for sake of example, the workflow of the patients 410 employs ascanner 420 used in medical imaging. An embodiment of the scanner 420includes an imager 422 (e.g., CT imaging system, PET imaging system,x-ray imaging system, MR imaging system, ultrasound imaging system,etc.) that generally performs the imaging function of the scanner 420. Ascanner agent 424 is created to track one or more properties of thescanner 420 or imager 422 employed in the clinical procedure. Forexample, the scanner agent 424 can track a capacity of the scanner 420,or a failure status of the scanner 420. The scanner agent 424 isoperable to communicate or collaborate with each of the patient agents415 directed to each of a series of patients 410, as well as otheragents (not shown) directed to other medical or clinical devices (notshown).

The embodiment of the system 400 also includes a bidding engine 426,similar to the bidding engines 140 and 344 described above. Inaccordance to the priority statuses communicated by the agents 415 ofthe patients 410 and the agent 424 of the scanner 420 (e.g., capacity),the bidding engine 426 creates or calculates a bid value of each patient410 for a slot in the schedule of the scanner 420. In creating theschedule of slots, the bidding engine 426 complies with predetermined oradded bidding policies that generally define boundary conditions of thepatient 410, scanner 420, and workflow. Alternatively, anotherembodiment of the bidding engine 426 can communicate with a schedulingdevice 428 to assign or identify each patient 410 to respective slots inthe schedule of use or availability of the scanner 420. The biddingengine 426 is operable to re-create or change the schedule in accordanceto unpredicted changes in the priority statuses that may occur as thepatients 410 progress through the workflow (e.g., clinical procedure).For example, if the patient agent 415 communicates to change one of thepatients 410 to a critical condition and associated high prioritystatus, the bidding engine 426 at any point in time of the workflow canrecalculate the bids for the one or more of the series of patients 410such that the high priority patient 410 progresses at the highestpriority status through events (e.g., schedule of the imager 422) of theworkflow in the least amount of wait time relative to the other lowerpriority status patients 410.

The system 400 can also include a broker 430 in communication with thebidding engine 426 and agents 415, 424 of the patient 410 and scanner420, respectively. If a capacity of the scanner 420 is limited, thebroker 430 may generate a message or report or purchase order thatrequests addition of another scanner 435 (shown in dashed line) to theworkflow. The broker 430 can also be operable to modify the steps orevents of the workflow. For example, the broker 430 may communicate aninstruction that causes the scanner 420 to skip one or two steps in theworkflow in response to one or more tracked properties communicated fromthe agents 415 or 424.

The system 400 is also operable to generate a report 440 of the scheduleto each patient 410 or to the technicians or clinicians involved in theworkflow. This information can be generated and reported in advance soas to reduce the preparation time of the patients 410 for the clinicalprocedure. By the time a first patient 410 completes one or more stepsof the clinical procedure, a next patient 410 can be prepped and readyaccording to the schedule. Updates to the schedule can be reported tothe patients 415 who have not yet arrived for the clinical procedure oras the changes are made by the bidding engine 426 or broker 430 inresponse to changes in the tracked properties of the patients 410 orscanner 420 during progression of patients 410 through the workflow.

In another example, assume the workflow includes steps in a process ofadministering nuclear medicine into the patient 410 to enhance imagine.If the patient agent 415 or scanner agent 424 tracks or detects a changein a patient 410 wait profile such that a number of patients 410 thathave received the nuclear medicine exceed a number of untreated patients410, then the agents 415 and 424 in communication with the biddingengine 426 are operable to modify the schedule of each patients 410 soas to cause the number of treated patients 410 to be reduced relative tothe number of untreated patients. The system 400 can also run mixedclinical populations, and use the diagnostic test request code as partof the mechanism of the bidding engine 426.

FIG. 5 is an illustration of another embodiment of a system 500 tomanage a workflow of a patient 510 through a procedure that employs oneor more scanners 515. Assume that the system 500 collects or acquirespatient information (e.g., patient identification, blood pressure,self/pre-assessment, etc.) from each patient 510 at the time ofadmission of the patient 510 to the entity (e.g. hospital, clinic).Based on the gathered information, an agent 518 is created to track aseries of properties 520 identified for each patient 510. For example,the properties 520 can be identified according to a clinical conditionof the patient 510 and/or based on a self/pre-assessment test of thepatient 510. The system 500 includes a patient database 522 to store thedata of the tracked properties 520 (e.g., patient information such aspatient identification (ID), other gathered or tracked information, ormeasured statuses or values of the various tracked properties by theagent 518). An embodiment of the patient agents 518 can also track theproperty for a time of waiting and/or progression through the workflow.The properties 520 can also represent a maximum wait period for eachpatient, where the elapse of the maximum wait period automaticallycreates a highest priority status to the respective patient 510. Assumethat the system 500 includes a scanner agent 530 to track one or moreproperties (e.g., current capacity) of the one or more scanners 515.

The agents 518 and 530 are operable to sense the presence and awareness,as described above with respect to system 100, so as to communicate andcollaborate in general real-time with one another, and to track theproperties of the patients 510 and scanner 515 through the workflow. Oneembodiment of the patient agent 518 communicates a current state ofactivity of the patient 510 to other agents 518 of other patients 510 orto the agent 530 of the scanner 515. From the collaboration, eachpatient agent 518 identifies a priority status of each respectivepatient 510 relative to the others in each of the slots in the scheduledoperation of the scanner 515, or simply next in the scheduled operationof the scanner 515.

The scanner agent 530 can be operable to track a failure status or thepatient handling capacity or other limiting property (e.g.,unavailability of operating technician or physician or clinician) of thescanner 515. The scanner agent 530 is generally configured to establisha general real time interaction between the agents 518 of the patients510 and the scanner 515. An embodiment of the scanner agent 530 isoperable to calculate track the properties of the scanner 515 and thecapacity of the scanner 515 (e.g., the capacity of the scanner 515) at agiven point of time, and collaborate with agents 530 of other scanners515 or the agents 518 of the patients 510, and can identify a prioritystatus of the scanner 515 to each patient 510.

FIG. 6 includes a schematic flow diagram illustrative of anotherembodiment of a method 600 to manage progression of the patient 105 withchest pain through the workflow of events employing resources 110, 112,114 as shown in FIG. 1. Assume for sake of example that the illustratedembodiment of resources are as follows: a physician 110, an operatingroom 112, and a cardiac catheterization system 114.

Step 620 includes identifying the patient 105 admitted and theavailability of the resources 110, 112, 114. Of course, the number ofpatients 105 and resources 112, 114, 116 can vary. Step 620 can alsoinclude identifying the set of properties 121 (e.g., a patient handlingcapacity, a wait time, or other factor identifying an unpredictedsituation in the workflow, etc.) of each patient 105 or properties 116,118, 120 of the resources 110, 112, 114 in the workflow.

Step 630 includes creating the agents 127 operable to track theproperties 121 of the patients 105, and agents 122, 124, 126 to trackproperties 116, 118, 120 of the resources 110, 112, 114, respectively,at any point in time of the workflow. The agents 122, 124, 126, 127communicate or collaborate with each other and communicate a prioritystatus or health risk of each patient 105 in view of availability of theresources 110, 112, 114 to the bidding engine 140 at any given time inthe workflow.

Step 645 includes the bidding engine 140 calculating the bid of each ofthe patients 105 for assignment to each slot in the schedule ofoperation of each resource 110, 112, 114 of the workflow, dependent onthe priority statuses communicated from the agents 122, 124, 126, 127.

Assume for sake of example, that the patient 105 is admitted with chestpain, and the patient agent 127 is created to track a wait time or oneor more symptoms of a heart attack. Also assume that the collaborationof the agents 122, 124, 126, 127 calculate the health or patient risk(e.g., probability of the patient 105 to develop into or become“critical” or death) is 60 percent. An embodiment of calculating thehealth risk can be dependent on the properties 121 of the patient, andstored data correlating tracked properties, admitted condition to healthrisk. Also assume that step 620 includes identifying the physician 110as the next critical resource in the workflow to treat the patient 105.Dependent on the priority statuses received by the bidding engine 140,the bidding engine 140 calculates the bid of the patient 105 to be avalue of 70, equivalent to a function of the calculated health risk(e.g., 60 percent) in addition to a value of 10 dependent on theavailability of the resource 110. One embodiment of the bidding engine140 calculates the bids of all of the patients 105 directed to each slotof the schedule of the physician 110. Alternatively, the bidding engine140 may calculate the bid of each patient 105 to be next in the scheduleof the physician 110. Step 650 includes the broker 150 comparing thebids, and calculating or assigning the patient 105 to one of the slotsin the schedule of the physician 110 dependent on the bids generated bythe bidding engine 140.

Step 655 includes another patient (shown in dashed line and by reference665 in FIG. 1) is admitted to the workflow, and an agent 670 created forthe patient 665 tracks that the second patient 665 is in a criticalcondition (e.g., state of shock). Assume that according to the storedhistorical data, agent 670 calculates a health risk of the patient 665to be 100 percent. According to the greater severity of the trackedstate of shock of the patient 665, the patient agent 670 in combinationwith the patient agent 127 automatically calculates and communicates tothe bidding engine 140 that the second patient 665 has a higher prioritystatus (e.g., greater health risk value of 100 percent) relative to thefirst patient 105 (e.g., health risk value of 60 percent). In response,step 675 includes the bidding engine 140 automatically re-calculating orupdating or altering the bid values of the first patient 105 relative tothe second patient 665. For example, assume the bidding enginere-calculates the bid of the second patient 665 to have a value of 90relative to a re-calculated bid of the first patient 105 to have a valueof 50. The type of tracked property (e.g., loss of consciousness,cardiac arrest, stroke, high/low blood pressure, etc.) that wouldtrigger the second agent 665 to increase the priority status of thesecond patient 665 relative the priority status of the first patient 105can vary. In view of the re-calculated bids received from the biddingengine 140, the broker 150 automatically re-schedules the second patient665 to a slot in the schedule of the physician 110 before the firstpatient 650.

Assume now that the patient 665 has been examined by the physician 110,and the first patient 105 is waiting for the next slot in the scheduleof the physician 100. The agent 127 tracks an increase in the wait timeof the first patient 105 to receive an examination by the physician 110relative to the others. With the increase in wait time, step 680includes the bidding engine 140 increasing the bid of the first patient105 relative to others that have less waiting time to receive anexamination by the physician 110. For example, assume the bidding engine140 increase the value of the bid by 1 with every incremental increasein wait time (e.g., every minute, every 10 minutes, etc.). The size ofthe increase in bid value relative to the incremental change in waittime can vary.

Step 685 includes the agent 127 detecting and communicating that thewait time of the first patient 105 to see the physician 110 has exceededa threshold. In response, step 690 includes the bidding engine 140adjusting the bid of the first patient 105 to exceed the bids of otherswaiting see the physician 110. For example, assume the threshold is waittime, the bidding engine 140 re-calculates the bid value of the patient105 to be 100 for the next slot in the schedule of the physician 110.The change in bid value with exceeding the threshold wait time can vary.Also, the type of thresholds (e.g., wait time, blood pressure, pulse,airway capacity, etc.) can vary. According to the change in the bid ofthe first patient 105, the broker 150 assigns the first patient 105 tobe assigned the next available slot in the schedule of the physician 110relative to other patients waiting to see the physician 110.

Step 695 includes receiving an examination and identifying or directingthe patient 105 to another resource 112 or 114. Assume that thephysician 110 identifies that a degree of arterial blockage of thepatient 105 should be measured with the cardiac catheterization system114. Step 700 includes the agent 127 in combination with the biddingengine 140 calculating a new bid value of the first patient 650 for aslot in the schedule of the cardiac catheterization system 114 relativeto bids of other patients waiting for the cardiac catheterization system114. Assume the initial bid value of the first patient 105 is 60 in viewof the data entered by the physician 110 to the system 100, and that thebroker 150 schedules the patient 105 in the next available slot in theschedule of the cardiac catheterization system 114.

Assume that examination by the cardiac catheterization system 114generates an output data or report to the controller 128 that quantifiesan arterial blockage of the first patient 105 that requires an operativeprocedure. Step 710 includes directing or identifying that the patient105 is to be directed to the operating room 112 so as to receive theoperative procedure to remediate the blockage. Now assume that thesystem 100 identifies the new properties to tracked by the agent 127relative to scheduling an opportunity in the schedule of the operatingroom 112 includes a wait time and the quantified blockage. Dependent onthe tracked properties of the patient 105 relative to other patients,step 715 includes communicating a priority status of the patient 105 tothe bidding engine 140, comparing the priority statuses received fromthe agent 127 relative to others, and creating the bid of the firstpatient 105 for a slot in the schedule of the available operating room112 relative to other patients scheduled or waiting for the operatingroom 112. Assume for sake of example that the agent 127 calculates thehealth risk of the patient 105 to be a value of 80 percent. In view ofthe risk value of the patient 105 relative to others waiting to bescheduled for the operating room 112, the bidding engine 140 calculatesthe bid value of the first patient for a particular slot (e.g., nextslot, each available slot) in the schedule of the operating room 112 tobe a value of 95, and increasing the bid value with wait time.

Step 720 includes the agent 124 of the operating room 112 detecting andcommunicating to the agent 127, or to the bidding engine 140, or to thebroker 150 that a capacity of the operating room 112 exceeds a threshold(e.g., exceeding patient capacity, surgeon, technician, nurse notavailable, etc.). Step 725 includes the broker 150 identifying orcalculating a next available option (e.g., stored data of alternative inmemory includes waiting in a cardiac care unit (not shown)). Step 730includes receiving the procedure in the operating room 112 andconcluding the workflow. Of course, the number of events or point ofconclusion of the workflow (e.g., discharge from operating room,discharge from hospital or clinic, completion of therapy, etc.) canvary.

FIG. 7 illustrates an embodiment of a dashboard 800 to illustrate outputdata of the system 100 shown in FIG. 1. Although described withreference to the system 100, the dashboard can also be part of thesystems 300, 400, and 500 described above. The dashboard 800 generallyincludes an illustration of each patient 105 admitted to the workflowaccording to an order of value of bids 805 directed to each of a seriesof slots 810 in the schedule of each of the available resources 110,112, 114 employed in executing the events of the workflow. Anillustration of the values of the bids 805 can also be listed, or thepatients 105 can merely be listed in numerical order of value of therespective bids. The dashboard 800 can further include a graphic displaygenerally illustrative of a geographic map 815 of the location,availability and current utilization of each of the resources 110, 112,114 that can be relative to a location of each patient 105. Theembodiment of the dashboard 800 can also include an alarm (e.g.,illumination of patient identification in a predetermined color, audiblealarm, etc.) indicative that respective agents 127 report that one ormore of the patients 105 exceeds a predetermined threshold (e.g., waittime) or is tracked to be in or approaching a predetermined criticalcondition (e.g., unconscious, threshold loss or increase in bloodpressure, cardiac arrhythmia, etc.). Any of the above-described trackedor calculated parameters can be illustrated in various combinations withone another at the dashboard 800. The dashboard 800 can further beoperable to receive input data or instructions via a keyboard,touchscreen, mouse device, or other known means to receive input.

FIG. 8 illustrates another embodiment of a dashboard 900 for graphicdisplay on a monitor or screen or other known similar device to anoperator. The dashboard 900 is generally configured to illustrate outputdata of the system 100 shown in FIG. 1 and described above. Althoughdescribed with reference to the system 100, the dashboard can also bepart of the systems 300, 400, and 500 described above. The dashboard 900generally includes an illustration of each of the value of bids 905generated by the bidding engine 140 for each of the one or more of theresources 110, 112, or 114 directed to each of a series of slots 910 inthe schedule workflow of each of the patients 105. As described above,the bidding engine 140 generates the bids dependent on received data ofthe tracked properties of the resources 110, 112, 114 (e.g., location ofresource relative to patient, failure condition, under repair orscheduled for maintenance after detected number of uses, dirty vs.clean, in current use, etc.) or patient 105. An illustration of thevalues of the bids 905 can be listed merely in numerical order of value.The dashboard 900 can further include a graphic display generallyillustrative of a geographic map 915 of the location, availability andcurrent utilization of each of the resources 110, 112, 114 that can berelative to a location of each patient 105. The embodiment of thedashboard 900 can also include an alarm (e.g., illumination of patientidentification in a predetermined color, audible alarm, etc.) indicativethat respective agents 127 report that one or more of the patients 105exceeds a predetermined threshold (e.g., wait time) or is tracked to bein or approaching a predetermined critical condition (e.g., unconscious,threshold loss or increase in blood pressure, cardiac arrhythmia, etc.).Any of the above- described tracked or calculated parameters can beillustrated in various combinations with one another at the dashboard900.

A technical effect of the above-described systems 100, 300, 400, and 500and methods 200 and 600 is to manage a workflow and respond to variouschanges in the properties of the resources (including patients) orworkflow in general real-time. Although the systems 100, 300, 400 and500 and methods 200 and 600 are described with respect to specifichealthcare environment, systems 100, 300, 400 and 500 and methods 200and 600 can be extended to any nature or type of workflow. Otherexamples include diagnostic equipment that supports multiple test typesreconfigures self to support high priority patient need. Alternatively,a department schedule can have one operational profile one day or evenone hour to suit a demand, and be reprogrammed with another operationalschedule to suit a different demand in time. The systems and methods arealso operable to create a schedule that accommodates combination orpermutations of conditions. Thereby, the systems and methods afford hugeflexibility and control of a workflow relative to those managed as onlya linear function.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow includes generatinga dynamic schedules based on dynamic properties of the resourcesinvolved in the process. In clinical workflows the dynamic propertiescan include a patient's current clinical condition and/or the staticconditions identified at admission through self/pre- assessments. Theabove-described systems 100, 300, 400, and 500 and methods 200 and 600are also operable cope with variance in patient wait time and processingtime relative to progression of tests and dynamic patient properties.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow is to facilitateenhanced management of workflows, generally in real time, where theworkflow might otherwise tend toward chaos due to complex conditionsthat evolve in general real time beyond the original workflow design.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 to manage a workflow includes employinga dynamic bidding process in general in general real-time to manage theworkflow. The above- described systems 100, 300, 400, and 500 andmethods 200 and 600 include defining dynamic properties, tracking theirproperties in real time, assigning a relative priority statusconsidering the properties of other resources or patients and biddingfor opportunities dependent on those priority statuses. The biddingpolicies can change dependent on, among other things, tracked propertiesof the various resources.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 an ability to manage the executionof the workflow in an adaptive manner. The above-described systems 100,300,400, and 500 and methods 200 and 600 are operable to change variousevents/steps of the workflow in general real time based on the trackedproperties of the resources and patients in the workflow. For example,the above-described systems 100, 300, 400, and 500 and methods 200 and600 are driven by dynamic changes in capacity of the resources andconditions of the patients.

Another technical effect of the above-described systems 100, 300, 400,and 500 and methods 200 and 600 includes an ability to change theoperational profile of the various resources such as medical equipmentinvolved in the workflow dependent on the properties of the patient orequipment. For example, the system 100, 300, 400, and 500 are operableto reconfigure medical diagnostic equipment that otherwise supportmultiple test types to instead support a high priority patient need, orto schedule patients on a basis of expected test times or steps along inthe test sequence.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 is to measure and increase athroughput of patients through a department or unit dependent on changesin the equipment, procedure, patient population and so on. Yet anothertechnical effect of the above-described systems 100, 300, 400, and 500and methods 200 and 600 is extending capacity by adding similar systemsin real time dependent on the tracked capacity of and load to be handledby the resources 110, 112, 114 at the given point in time.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 include an ability to testpermutations or simulations in response to the dynamic properties of thepatient population relative to need for service.

Yet another technical effect of the above-described systems 100, 300,400, and 500 and methods 200 and 600 includes providing an ability toemploy a real time bidding techniques to manage a workflow, includingdefining dynamic properties to each bidder, tracking their properties inreal time, assigning a relative priority status considering theproperties of other resources, and bidding for an opportunity basedpriority status. To resolve the priority status or to assign theopportunity, a set of bidding policies are implemented dependent onstatic and dynamic properties of the patients and resources in theworkflow at a given time.

Although the subject matter is described herein with reference tomedical diagnostic or cardiac treatment applications, it should be notedthat the subject matter is not limited to this or any particularapplication or environment. Rather, the subject matter may be employedor applied to any service provider to manage scheduling of multi-variantor non-linear workflows. Examples include workflows employing anultrasound diagnostic system, on-line trading wherein buyers and sellerskeep on adding and removing from the process, supermarkets, ambulatoryor other emergency service, etc. Also, it should be understood that oneor more of the steps or components of one of the systems 100, 300, 400,and 500 and methods 200 and 600 and dashboards 800 and 900 describedabove can be used with another of the method or systems or dashboardsdescribed above and is not limiting on the disclosure.

This written description uses examples to disclose the subject matter,including the best mode, and also to enable one skilled in the art tomake and use the disclosure. The patentable scope of the subject matteris defined by the following claims, and may include other examples thatoccur to those skilled in the art. Such other examples are intended tobe within the scope of the claims if they have structural elements thatdo not differ from the literal language of the claims, or if theyinclude equivalent structural elements with insubstantial differencesfrom the literal languages of the claims.

What is claimed is:
 1. A system to allocate a resource to a plurality ofpatients, the system comprising: a first agent to track a first propertyassociated with a first patient to obtain first tracking data and asecond agent to track a second property associated with a second patientto obtain second tracking data; a bidding engine to receive the firsttracking data from the first agent and the second tracking data from thesecond agent, the bidding agent to dynamically generate a first bidassociated with the first patient based on the first tracking data and asecond bid associated with the second patient based on the secondtracking data; and a broker to assign the resource to one of the firstpatient or the second patient, wherein the broker is to dynamicallycommunicate with the bidding engine to assign the resource based on atleast one of the first bid, the second bid, or a property associatedwith the resource.
 2. The system of claim 1, wherein the broker is tooptimize at least one of a wait time of one the first patient or thesecond patient for access the resource, a progression of the firstpatient or the second patient through a respective workflow, or autilization of the resource based on the assignment of the resource. 3.The system of claim 1, wherein the bidding engine is to calculate afirst value for the first bid and a second value for the second bid andthe broker is to weigh the first bid and the second bid to assign theresource.
 4. The system of claim 3, wherein the bidding engine is todynamically update the first value based on a change in the firsttracking data and the broker is to assign the first patient to theresource based on a change in the first value relative to the secondvalue.
 5. The system of claim 4, wherein the bidding engine is todynamically update the first value as the first patient progressesthrough a workflow and the broker is to adjust the workflow of the firstpatient and a workflow of the second patient by assigning the resourceto the first patient.
 6. The system of claim 3, wherein one of thebidding engine or the broker is to stimulate a third value for the firstbid and the broker is to compare a progression of the first patientthrough a workflow based the first value to the progression of the firstpatient through the workflow based on the third value.
 7. The system ofclaim 1, wherein the bidding engine and the broker are to negotiate anassignment of the first patient to the resource based on a change in thefirst property of the first patient relative to an assignment of thesecond patient to the resource prior to the change.
 8. The system ofclaim 1, wherein the broker is to assign one of the first patient or thesecond patient to a first scheduling slot of the resource and one of theother of the first patient or the second patient to a second schedulingslot of the resource or a second resource.
 9. The system of claim 1,wherein the first agent and the second agent are to track one or more ofphysiological property, a wait time, a clinical threshold, or acriticality level associated with the first patient and the secondpatient, respectively.
 10. The system of claim 1, wherein the propertyassociated with the resource is at least one of an availability statusor an operational condition.
 11. The system of claim 1, furthercomprising an interface to display a first patient identifier associatedwith the first patient and a second patient identifier associated withthe second patient, wherein the display of the first patient identifierand the second patient identifier is associated with the first bid andthe second bid.
 12. A method to allocate a resource to a plurality ofpatients, the method comprising: tracking a first property associatedwith a first patient to obtain first tracking data and a second propertyassociated with a second patient to obtain second tracking data;dynamically generating a first bid associated with the first patientbased on the first tracking data and a second bid associated with thesecond patient based on the second tracking data; and assigning theresource to one of the first patient or the second patient based on atleast one of the first bid, the second bid, or a property associatedwith the resource.
 13. The method of claim 12, further comprising:calculating a first value for the first bid and a second value for thesecond bid and wherein the broker is to weigh the first bid and thesecond bid to assign the resource; and weighing the first bid and thesecond bid to assign the resource.
 14. The method of claim 13, furthercomprising: dynamically updating the first value based on a change inthe first tracking data; and assigning the first patient to the resourcebased on a change in the first value relative to the second value. 15.The method of claim 14, further comprising: dynamically updating thefirst value as the first patient progresses through a workflow; andadjusting the workflow of the first patient and a workflow of the secondpatient by assigning the first patient to the resource.
 16. The methodof claim 12, further comprising displaying a first patient identifierassociated with the first patient and a second patient identifierassociated with the second patient, wherein displaying the first patientidentifier and the second patient identifier is based on the first bidand the second bid.
 17. A machine readable storage device or disc,containing instructions thereon, which when read cause a machine to atleast: track a first property associated with a first patient to obtainfirst tracking data and a second property associated with a secondpatient to obtain second tracking data; dynamically generate a first bidassociated with the first patient based on the first tracking data and asecond bid associated with the second patient based on the secondtracking data; and assign the resource to one of the first patient orthe second patient based on at least one of the first bid, the secondbid, or a property associated with the resource.
 18. The machinereadable storage device or storage disc of claim 17, wherein theinstructions cause the machine to: calculate a first value for the firstbid and a second value for the second bid and wherein the broker is toweigh the first bid and the second bid to assign the resource; and weighthe first bid and the second bid to assign the resource
 19. The machinereadable storage device or storage disc of claim 18, wherein theinstructions cause the machine to: dynamically update the first valuebased on a change in the first tracking data; and assign the firstpatient to the resource based on a change in the first value relative tothe second value.
 20. The machine readable storage device or storagedisc of claim 17, wherein the instructions cause the machine to displaya first patient identifier associated with the first patient and asecond patient identifier associated with the second patient, whereinthe instructions cause the machine to display of the first patientidentifier and the second patient identifier based on the first bid andthe second bid